Method, computer-readable medium, and system for discovery and registration of controlled devices associated with self-describing modules

ABSTRACT

A system, method, and computer-readable medium for the discovery and registration of controlled devices associated with self-describing Modules in a control system are provided. A controlled device associated with a self-describing module is coupled with a master controller on which the self-describing module is installed. A remote monitoring system is communicatively coupled with the master controller, and a remote monitoring system agent is installed on the master controller. The agent discovers a Module associated with the controlled device and queries the Module for a version thereof. The agent then evaluates whether the Module is self-describing. In the event the Module is self-describing, the agent requests a run-time capabilities object from the Module and registers the controlled device with the remote monitoring system according to the capabilities object.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority to and is a continuation of U.S. patentapplication Ser. No. 12/344,723, entitled “METHOD, COMPUTER-READABLEMEDIUM, AND SYSTEM FOR DISCOVERY AND REGISTRATION OF CONTROLLED DEVICESASSOCIATED WITH SELF-DESCRIBING MODULES”, by Birze, et al., filed onDec. 29, 2008, now issued U.S. Pat. No. 8,954,541, issued on Feb. 10,2015, which claim priority to U.S. provisional patent application Ser.No. 61/017,613, entitled, “Self Describing Devices”, filed Dec. 29,2007, by Birze, et al. and U.S. provisional patent application Ser. No.61/017,620, entitled, “Sever Enabled Device Description”, filed Dec. 29,2007, by Birze, et al., the disclosures of which are incorporated hereinby reference.

FIELD OF THE INVENTION

The present invention is generally related to control systems and, moreparticularly, to mechanisms for the production of self-describingcontrolled device Modules in a control system.

BACKGROUND OF THE INVENTION

Many systems, such as control systems, monitoring systems, and the like,exist that allow discovery at runtime of devices active in the system.These systems may also discover a device's type thereby allowing basiccontrol and monitoring with no external configuration. However, thesesystems depend on standardized application programming interfaces (APIs)describing Parameters, Properties, and Control Commands for differentdevice types. Once a device of a known device type is found, the systemcan use a standardized API for the device type to control, configure, ormonitor the device. For example, some of the attributes of securitysystem device types include Properties, such as a manufacture and model,Parameters, such as arm-able state (ability to arm a system) andsecurity state, (such as ARM_HOME, ARM, DISARM, and PANIC), and Commands(such as GetSecurityStatus, setSeucrityState, and is OKToArm).

Unfortunately, many devices have capabilities that do not fit intostandardized device type APIs. This particular trend is becoming moreprevalent as manufacturers merge multiple capabilities into a singledevice, e.g., placing a DVD and a VCR in the same device housing.

Companies that support standardized device type APIs must frequentlyupdate their APIs to keep up with the latest innovations by devicemanufactures. This causes deployment issues as the control, monitoring,and integration systems that understand the APIs must be updated tounderstand devices using the latest APIs.

Many device protocols allow manufactures to add extensions to theirdevice type API to allow the manufacturers to expose their devices'unique capabilities. However, custom code must then be developed andinstalled in the control or monitoring system to allow the system toutilize a device's extensions thereby requiring intimate knowledge ofthe control or monitoring system's internals. Additionally, custom codein a control or monitoring system hampers the ability to swap one deviceof a type for another of the same type. For example, custom code writtenfor a receiver with custom capabilities will not perform when thereceiver is swapped for one that does not have the custom capabilities.

Therefore, what is needed is a mechanism that overcomes the describedproblems and limitations.

SUMMARY OF THE INVENTION

The present invention provides a system, method, and computer-readablemedium for the discovery and registration of controlled devicesassociated with self-describing Modules in a control system. Acontrolled device associated with a self-describing Module is coupledwith a master controller on which the self-describing module isinstalled. A remote monitoring system is communicatively coupled withthe master controller, and a remote monitoring system agent is installedon the master controller. The agent discovers a Module associated withthe controlled device and queries the Module for a version thereof. Theagent then evaluates whether the Module is self-describing. In the eventthe Module is self-describing, the agent requests a run-timecapabilities object from the Module and registers the controlled devicewith the remote monitoring system according to the capabilities object.In the event a Module associated with another device is discovered thatis not self-describing, the agent may generate a capabilities object andregister the other device with the remote monitoring system according tothe generated capabilities object.

In one embodiment of the disclosure, a method of discovery andregistration of a controlled device for control thereof is provided. Themethod includes discovering a Module associated with the controlleddevice by an agent associated with a remote monitoring system,evaluating whether the module is self-describing, responsive todetermining the module is self-describing, requesting a run-timecapabilities object from the Module, receiving the capabilities object,and registering the controlled device with the remote monitoring systemaccording to the capabilities object.

In a further embodiment of the disclosure, a computer-readable mediumhaving computer-executable instructions for execution by a processingsystem, the computer-executable instructions for discovery andregistration of a controlled device for control thereof is provided. Thecomputer-readable medium includes instructions that, when executed,cause the processing system to discover a Module associated with thecontrolled device by an agent associated with a remote monitoringsystem, query the Module for a version of the Module, evaluate whetherthe Module is self-describing, responsive to determining the Module isself-describing, request a run-time capabilities object from the Module,receive the capabilities object, and register the controlled device withthe remote monitoring system according to the capabilities object.

In a further embodiment of the disclosure, a control system for controlof controlled devices deployed therein is provided. The control systemincludes a controlled device having a self-describing Module associatedtherewith, a remote monitoring system, and a master controller on whichthe self-describing Module and an agent associated with the remotemonitoring system are installed. The remote monitoring system and themaster controller are OSGi-compliant. The agent discovers the Module byinvoking an OSGi method, queries the Module for a version of the Module,determines the Module is self-describing, requests a run-timecapabilities object from the Module responsive to determining the Moduleis self-describing, receives the capabilities object, and registers thecontrolled device with the remote monitoring system according to thecapabilities object.

BRIEF DESCRIPTION OF THE DRAWINGS

Aspects of the present disclosure are best understood from the followingdetailed description when read with the accompanying figures, in which:

FIG. 1 is a diagrammatic representation of a contemporary control systemconfiguration that provides for control and monitoring of controlleddevices deployed in the control system;

FIG. 2 is a diagrammatic representation of a control systemconfiguration that facilitates controlled device Module development anddeployment in accordance with embodiments;

FIG. 3 is a diagrammatic representation of a controlled device Moduleand controlled device development and deployment work flow implementedin accordance with an embodiment;

FIG. 4 is a flowchart that depicts a controlled device Module creationroutine implemented in accordance with an embodiment;

FIG. 5 is a diagrammatic representation of a Module package classstructure implemented in accordance with disclosed embodiments;

FIG. 6 is a flowchart that depicts processing of a remote monitoringsystem agent discovery and registration routine in accordance with anembodiment; and

FIG. 7 is a flowchart that depicts processing of a control routine forcontrolling or accessing a controlled device in accordance with anembodiment.

DETAILED DESCRIPTION OF THE INVENTION

It is to be understood that the following disclosure provides manydifferent embodiments or examples for implementing different features ofvarious embodiments. Specific examples of components and arrangementsare described below to simplify the present disclosure. These are, ofcourse, merely examples and are not intended to be limiting.

In accordance with disclosed embodiments, a self-describing controlleddevice Module allows a device to describe itself both at runtime andbefore installation thereby allowing discovery of the capabilities ofthe device to enable control, monitoring, and integration of a devicewith no prior knowledge of the device or the device type. Additionally,custom extensions to a device's capabilities will also be discovered toallow control, monitoring, and integration of these custom extensionswithout the need for custom code. New devices may then be deployed, orcommunicatively coupled with, control systems, monitoring systems,configuration tools, or development tools and natively understood withno changes to the systems or tools.

Contemporary products may use the application programming interfaces andcorresponding device types to provide integration and control of devicesin a control system. Exemplary attributes of the Security System devicetype include Properties, such as manufacture and model, Parameters, andCommands. However, many devices have capabilities that do not fit intosuch standardized APIs, and the trend is becoming more prevalent asmanufacturers merge multiple capabilities into a single device.

In accordance with disclosed embodiments, mechanisms for provisioning aself-describing controlled device Module are provided. As referred toherein a device Module comprises a component that allows a device to bedeployed in a control or remote monitoring system (collectively referredto herein simply as a control system). The device Module may beimplemented as computer-executable or computer-readable instructionstangibly embodied on a computer-readable medium. A device, such as acamera, tuner, or any other device that may be monitored, controlled, orotherwise manipulated via the control system, is referred to herein as acontrolled device. A controlled device has a corresponding device Modulethat facilitates deployment and operation of the controlled devicewithin the control system. The control system may include various systementities or nodes that facilitate controlled device configuration anddeployment, management, operation, control, monitoring, or othermanipulations of a controlled device. Control system entities arereferred to herein as control system devices (or simply system devices).Exemplary system devices include, for example, a master controller, aremote monitoring system (RMS), and any variety of IntegratedDevelopment Environment (IDE) systems or tools used for deviceintegration, deployment or configuration.

The self-describing device Modules implemented according to disclosedembodiments are able to describe the capabilities of a controlled deviceboth at runtime and before installation. Advantageously, the discoveryof the capabilities of the device by other system devices with no priorknowledge of the device or its device type is provided. A mastercontroller is able to control the controlled device, an RMS is able tomonitor the controlled device, and an integration IDE is able tointegrate the device Module with no changes to other control systemdevices. Additionally, custom extensions to device APIs may be allowedand may also be discoverable to allow control, monitoring, andintegration of these custom extensions without the need for custom code.

FIG. 1 is a diagrammatic representation of a contemporary control system100 configuration that provides for device control and monitoring incontrol system 100. A controlled device development IDE 110 may be usedby device manufactures, e.g., a manufacturer of a controlled device 170,to develop a Module for the corresponding controlled device.Alternatively, the development IDE 110 may be used by manufacturers ordevelopers of control system devices. A Module provides customizedcontrol and monitoring for a specific controlled device model from aspecific manufacturer in a control system 100.

An integration IDE 130 allows device dealers to easily integratemultiple Modules and their associated controlled devices into a singlecontrol system 100. An integration tool run at integration IDE 130 mayprovide a visual mechanism of generating Touchpanel glue code to tie,for example, touch panel 142 inputs with each device Module's API tocontrol and monitor the associated device.

Modules integrated with integration IDE 130 may be loaded onto a mastercontroller 140 to enable control of the corresponding devices in thecontrol system 100. NetLinx code generated by integration IDE 130 mayalso be loaded onto the master controller 140 to link touch panels, orother peripheral devices, with the control and monitoring APIs exposedby the device Modules generated by development IDE 110.

A remote monitoring system (RMS) 160 may feature a resource managementsuite that provides remote monitoring and control of various controlleddevices 170 integrated in control system 100. The RMS 160 may comprisean RMS server that communicates with RMS agents installed on the systemmaster controller 140. The RMS enables administrators to gather statusof controlled devices and to control the devices participating in thecontrol system 100 that are deployed via the master controller 140.Various control system devices are communicatively coupled with oneanother, e.g., via a network 150, a direct connection, or anothersuitable interface.

Contemporary API specifications create a control system which providesrigid device development, yet does not provide effective runtimeenforcement. This introduces ambiguity and creates issues for controlsystem devices or products collaborating to provide control andmonitoring for controlled devices deployed in control system 100.

A control system device software development kit (SDK) composed of SDKcomponents is used to create Modules for controlled devices. SDKcomponents each expose an API that describes the mechanisms forcontrolling and monitoring the common device component. For example, aPower Supply is a device component used in many device types and thusmay have a corresponding Power Supply SDK component at the developmentIDE 110.

Typical SDK components are grouped into well know device types which arerigid in their structure. These well known device types cannot easilyaccount for device innovations in the form of new functionality orcombinations of different device types. For example, a VCR comprises apower supply, a television tuner, and a tape transport. A device typespecified as a VCR may then have a respective SDK component for thepower supply, television tuner, and the tape transport. In a similarmanner, a DVD player comprises a power supply and a disc transport. Adevice type specified as a DVD player may have a respective SDKcomponent for the power supply and the disc transport. In this manner,well known device types may be accommodated by various automated toolsfor configuration and deployment in a control system. However, considera manufacturer that has produced a DVD/VCR combination. In thisinstance, another device type must be defined for efficient deploymentof the DVD/VCR combination since neither the SDK components grouped intothe VCR device type nor the SDK components of the DVD device type mayappropriately address the combination device.

Module developers may add custom capabilities as custom events, butthese are not natively understood by any tools or control system devicesor products requiring, for example, custom Touchpanel code to utilizethe unique device capabilities. Thus, a device SDK must bedisadvantageously updated periodically to accommodate new or modifieddevice types. Consequently, controlled device deployment issues areoften encountered as the system master controller 140 can support onlyone version of the device APIs. If an updated API “breaks” a legacyModule's existing functionality, the legacy Module must be “reopened” toaccount for the updated APIs in order to function on new control systeminstallations. This ongoing SDK and Module maintenance consumes softwareengineering and development time, aggravates system partners that maynot be aware of SDK updates, and complicates integration and deploymentfor product dealers.

Integration IDE 130 may import a Module's generated module.xml file todetermine the device type and the Commands, Parameters, and Propertiesavailable for the Module. This data is checked against the expectedCommands, Parameters, and Properties for the device type from the mostrecent Device SDK API. If there is a mismatch due to an out of dateModule, the mismatched commands will not appear in the code builder andthus will not be available to the system integrator. Custom commands andevents representing extensions to the standard device type are notexposed to integration IDE 130 and cannot be exposed to the systemintegrator.

In accordance with disclosed embodiments, a device Module configurationrelaxes the rigidity of development while enforcing runtime access toonly defined Commands, Parameters, and Properties. This shift inperspective eliminates the frustration of Module developers not beingable to “fit” their device capabilities into a pre-defined device SDK.Module developers are able to mix and match standard SDK components toaccommodate new device combinations while also creating custom commandsand events to capture unique device capabilities in accordance withdisclosed embodiments. A development IDE captures this information andgenerates a framework that describes the capabilities of the Module.

Central to the disclosed controlled device Module implementation is thecreation of a capabilities component. When queried, a Module'scapabilities component is able to describe its Module's capabilitiesboth as a capabilities object that can be queried at runtime and in anXML format, or other instruction set, that can be saved or passed inmessages between control system devices, such as the master controllerand RMS. This same capabilities component will be able to create aruntime capabilities object from consuming the self-describing XML file.

FIG. 2 is a diagrammatic representation of a control systemconfiguration that facilitates controlled device Module development anddeployment in accordance with embodiments.

A controlled device Module development IDE 210 may be used by controlleddevice manufactures, e.g., manufacturers of controlled and monitoreddevices 270-271, or control system device manufacturers to developself-describing Modules for corresponding controlled devices.

An integration IDE 230 allows device dealers to integrate multipleModules and their associated controlled devices into a single controlsystem. An integration code builder tool run at integration IDE 230 mayprovide a visual mechanism of generating Touchpanel glue code to tie,for example, touch panel inputs with each device Module's API to controland monitor the associated controlled device.

Modules integrated with integration IDE 230 may be loaded onto a systemmaster controller 240 to enable control of the controlled devices in thecontrol system.

An RMS 260 provides remote monitoring and control of various controlleddevices 270-271 integrated in control system. The RMS may comprise aresource management suite that communicates with RMS agents installed onthe system master controller 240. RMS 260 enables administrators togather status of controlled devices and to control the devicesparticipating in the control system deployed via master controller 240.

Each Module facilitates control and monitoring for a correspondingcontrolled device in control system. In accordance with an embodiment, aModule package 290 is produced by development IDE 210 that includes thedevice Module 292 and a capabilities component (CC) 293 that facilitatesdevice deployment and operation within the control system. In accordancewith an embodiment, a CC is provided for each controlled device type.Thus, controlled device 270 may have a CC 293 associated therewith, andcontrolled device 271 may have a CC 295 associated therewith. The RMS260 may access each CC 293 and 295 of associated controlled devices270-271. The Module package, such as Module package 290, and constituentcomponents are associated with a particular controlled device, such ascontrolled device 270. A corresponding capabilities component 293includes a self-describing XML file 296, or other suitable instructionset, that specifies the capabilities of the corresponding controlleddevice 270 including Properties, such as the device manufacturer andmodel, Parameters, such as controlled device 270 parameter states andstatus, and commands. As referred to herein, Parameters are mutablevalues describing the state of the controlled device. Parameters can bequeried or delivered as asynchronous events. Properties are immutablevalues describing the controlled device, such as a manufacturer andmodel. Control Commands comprise methods which can be invoked to controlthe device to change the controlled device 270 configuration or state.

A capabilities component, such as CC 293, is configured to be queried byone or more control system devices including configuration, integration,and deployment tools, e.g., integration IDE 230 and RMS 260, and returnModule capabilities in response to the query. The Module capabilitiesmay be provided by the capabilities component as the XML file 296 priorto complete operational configuration of the Module 292 andcorresponding controlled device 270. Further, the self-describing XMLfile 296 may be conveyed between one or more control system devices orcomponents. When the device Module 292 and corresponding controlleddevice 270 are operationally deployed within the control system, acorresponding capabilities component 293 may generate a capabilitiesobject 298 from the self-describing XML file 296. At this point,response to runtime queries issued to the capabilities component 293 maybe provided by the capabilities object 298.

Various control system devices, such as the integration IDE 230, RMS260, and master controller 240 may access a respective capabilitiescomponent, such as CC 293. The capabilities component allows for strictenforcement during integration of the corresponding controlled device270 within the control system and during controlled device 270 runtime.

The controlled device 270 is coupled with the master controller 240 andis thereby provisioned a communication interface with the correspondingModule 292. When the Module and controlled device are operationallyconfigured within the control system 200, supported control andmonitoring commands may be conveyed from the Module 292 to thecontrolled device 270. To this end, the controlled device Module maycommunicatively interface with a remote monitoring agent 246 that,itself, may be communicatively coupled with RMS 260, e.g., via a networkconnection, a direct connection, or other suitable communication medium.The remote monitoring agent 246 may include or interface with aninstance of the self-describing XML file 296. At runtime, the remotemonitoring agent 246 may obtain the capabilities component 293 in theform of the capabilities object 298. When the controlled device isregistered with RMS 260, an administrator may issue control andmonitoring commands that are received by the remote monitoring agent 246associated with the controlled device 270.

The controlled device Module 292 additionally interfaces with acontrolled device router 244 that is allocated for, and associated with,the controlled device 270. The router 244 is identified and loaded bythe master controller 240 to enable communications between Touchpanelcode 242 and the code environment, e.g., Java, in which Module 292 isdeployed. To this end, Module 292 may include a manifest that specifiesthe router 244 to be loaded and associated with Module 292, and mastercontroller 240 is configured to examine the Module's manifest for suchpurposes. When loaded, the router 244 will query the associated Module292 to discover its capabilities via a returned capabilities object(illustratively represented as a capabilities component 298). Only thecapabilities described by the Module 292 will be sent to, or receivedfrom, the router 244. Commands or monitoring requests conveyed to therouter 244 that are not included in the Module's capabilities objectwill be returned with a “not implemented” error or other suitable fault.Other controlled devices 271-272 may have corresponding Modules,associated RMS agents, and routers configured on master controller 240.

The control system may accommodate controlled devices, such as acontrolled device 271, that has a legacy controlled device Module 294and a corresponding router 245. Legacy controlled device Module 294 doesnot have the ability to provide capabilities of the controlled device273, both rather may only provide a device type and version, e.g., toremote monitoring agent 246.

FIG. 3 is a diagrammatic representation of a controlled device Moduleand controlled device development and deployment work flow 300implemented in accordance with an embodiment.

A device Module is produced at development IDE 210 (step 302). Thecontrolled device Module 292 created at the development IDE 210 includesa self-describing capabilities XML file 296 for use prior to completeconfiguration of the controlled device 270 and corresponding Module 292within control system. The Module 292 includes suitable logic forcreating and exposing a capabilities object 298 and/or a self-describingXML file 296 for use at runtime, i.e., when the controlled device andModule are operationally configured for use in control system. Anintegration IDE 230 may then access the controlled device Module 292 toobtain the self-describing XML file 296 (step 304). On receipt of theself-describing XML file 296, the integration IDE 230 use the XML file296 to integrate the controlled device's exposed capabilities into thecontrol system. Once the device's capabilities are integrated into thecontrol system such that the controlled device and Module areoperationally configured, the master controller 240 may retrieve theruntime capabilities object from the Module 292 and thereby controlaccess to the Module and the corresponding controlled device (step 306).The master controller utilizes the runtime capabilities object 298 toallow or prohibit monitoring requests and commands issued for thecontrolled device 270 according to the capabilities advertised orotherwise provided by the capabilities object 298. The remote monitoringsystem 260 may likewise obtain the controlled device Module'scapabilities object (step 308), and the remote monitoring system mayregister the controlled device accordingly (step 310). The remotemonitoring system uses the capabilities description provided by thecapabilities object to advertise the device capabilities to a remotemonitoring system administrator. The administrator may then complete amonitoring and control configuration for the device that is constrainedby the device capabilities advertised by the controlled devicecapabilities object. Monitoring and control of the controlled device maythen be performed by issuance of suitable commands from the remotemonitoring system to the device Module 292 (step 312).

The development IDE 210 used for creation of the device Module accordingto step 302 may include an SDK that features low-level, reusable,controlled device SDK component building blocks, e.g., power supply, keypad, sensor device, or other common SDK components. However, the use ofSDK components for creation of a Module 292 implemented in accordancewith embodiments advantageously does not rely on module indexing, e.g.,the association of one or more SDKs with a particular controlled devicetype. Rather, SDK components that are available and that may be utilizedfor Module development are not bound by a particular device type, andthus Module developers may freely mix and match SDK components. Further,the SDK preferably provides mechanisms for creating custom events andcommands for the controlled device that may be accommodated by thecorresponding Module. Advantageously, development and deployment ofcontrolled devices within the control system does not require any rigidnotion of a device type and a required SDK components association.Module developers are able to create their own device types or,alternatively, start with a known device type and remove or add SDKcomponent at will.

Completed controlled device Modules developed at development IDE 210 arepackaged for installation on master controllers. Completed Modulesemploy a capabilities component 293 to allow the Module to provide adescription of the services it offers as both a runtime capabilitiesobject 298 and in a self-describing XML file 296.

FIG. 4 is a flowchart 400 that depicts a controlled device Modulecreation routine implemented in accordance with an embodiment. Theprocessing steps of FIG. 4 may be implemented as computer-executableinstructions executable by a processing system, such as the developmentIDE 210 depicted in FIG. 2.

The Module creation routine is invoked (step 402), and the Moduledesigner may be presented with various SDK components for selection toinclude in the Module for a corresponding device component (step 404).If the designer selects an SDK component, the metadata on the API isthen specified including valid parameter ranges and values,descriptions, etc. (step 406). Specification of the interface API mayinclude specifying one or more commands, parameters, and/or propertiesand may include the specification of metadata including descriptions,parameters types, and valid ranges. Once the selected SDK componentfunction's interface API has been defined by the designer, the designermay choose an additional SDK component according to step 404.

When no additional SDK components are selected by the Module designer,the designer may be provided an option to specify custom commands (step408). If the designer so chooses, the designer may extend a customcomponent API by the specification of custom commands or events for theModule 292 (step 410). In an embodiment, the IDE 210 may providerequired fields to facilitate generation of a corresponding customcomponent. For example, the IDE 210 may require the designer to specifyone or more Commands, Properties, and Parameters that are to beassociated with the custom command or event, and may require the supplyof metadata including descriptive text and valid ranges of the one ormore Commands, Properties, or Parameters. After specification of thecustom command or event and corresponding Commands, Properties, and/orParameters and associated descriptive text and metadata, the IDE 210 maythen generate a self-describing capabilities component for theSDK/custom component (step 412). The custom component generated by IDE210 encapsulates the device's custom commands and events. Thereafter,the IDE 210 may then generate a device class skeleton for the SDK andcustom component (step 414). A device class implementation is then addedto control the specific device (step 416). A composite capabilitiescomponent may then be generated from each of the capabilities and customcomponents (step 418). In an embodiment, the composite capabilitiescomponent may comprise a self-describing XML file 296 from which Module292 may generate a runtime capabilities object when Module 292 isoperationally configured and deployed in control system. A manifest maythen be generated for Module 292 (step 420). In an embodiment, themanifest generated for the Module 292 may specify a generic router 244that is adapted to interface with self-describing Module 292. Thecompleted Module package 290 is then produced by IDE 210 (step 422). Inan embodiment, the Module package 290 includes the generated manifest,the chosen SDK components, custom components, and the compositecapabilities component 293 including the generated self-describing XMLfile 296. The Module creation routine cycle may then end (step 424).

FIG. 5 is a diagrammatic representation of a Module package 290 classstructure 500 implemented in accordance with disclosed embodiments.Module package 290 may be implemented as instruction sets tangiblyembodied on a computer-readable medium and executable by a processingsystem, such as development IDE 210.

In the illustrative example, the Module package 290 class structure 500depicts an exemplary class diagram of a packaged Module for control of acontrolled device comprising a tuner 510. The module package 290 mayinclude various device SDK component classes including, for example, aDevice Power SDK class 531, a Device Preamp SDK class 532, and a DeviceTuner SDK class 533. Additionally, a Device Custom Features class 530specifies custom commands or events specific to tuner 510. Correspondingdevice component classes are generated for each of the SDK classes andthe custom class(es). For example, a Power Device Component class 541 isgenerated and included in the Module package that corresponds to theDevice Power SDK class 531. Likewise, a Preamp Device Component class542 is included in the Module package 290 that corresponds to the DevicePreamp SDK class 532, and a Tuner Device Component class 543 is includedin the Module package 290 that corresponds to the Device Tuner SDK class533. A Custom Device Component class 540 is generated by the developmentIDE 210 and provides the API to the custom commands, events, andlisteners specific to the tuner 510 that are provided by the DeviceCustom Functions class 530. All Device SDK Component classes 541-543inherit from a Device Component base class 570 which provides aconsistent interface to the OSGi framework.

Each of the Device SDK classes 531-533 comprise abstract classes thatare selected by the Module developer. The Module developer specifies theinterface APIs providing the functionality of the abstract SDK classes531-533 thereby providing the requisite logic for the correspondingdevice component classes 541-543 to implement specific device accesscodes for properly interfacing with tuner 510. The Module developerspecifies custom commands or events for defining the Device CustomFeatures class 530. Custom Device Component class 540 is generated bythe development IDE 210 and provides the API to the custom commands,events, and listeners specific to the tuner 510 that are provided by theDevice Custom Functions class 530. A utility access class, e.g., SerialAccess Utility class 520, may be provisioned at the development IDE 210to simplify development of device component classes 540-543 andcorresponding API specifications for utility access via SDK Componentclasses 531-533 and custom classes, e.g., Device Custom Functions class530.

In accordance with an embodiment, Module package 290 and control system200 software entities are implemented in compliance with the OSGiframework, although other suitable frameworks may be substitutedtherefor. An OSGi Device class 560 and Capabilities class 550 are hiddenfrom the Module developer. The OSGi Device class 560 providesinteraction with the OSGi framework and is the communication point forall services outside the Module bundle. The Capabilities class 550 isgenerated by development IDE 210 and determines all the components andcustom commands and listener events specified in the Module. In anembodiment, the Capabilities class 550 uses Java reflection to match thecommands, parameters, and properties listed in the capabilities Objectwith the actual methods in the objects that satisfy the capabilities.

At startup, each Device Component class 540-543 will be queried fortheir runtime capabilities object that includes the commands,parameters, and properties offered by the Module as well as metadataincluding descriptions, parameters types, and valid ranges. Individualcapabilities objects of Component classes 540-543 may be accumulated bythe Capabilities class 550 for collection of composite capabilities ofall device component classes 540-543. When queried, the OSGi Deviceclass 560 obtains the composite capabilities from the Capabilities class550 and returns a composite runtime capabilities object describing thecapabilities of device 510. The OSGi Device class 560 exposes a serviceinterface other services will use to invoke command or request parameteridentifiers from the associated Capabilities Object.

In accordance with another embodiment, RMS 260 is comprised of an RMSserver that communicates with remote monitoring agents 246 installed onmaster controller 240 to gather status or control the controlled devices270-273 deployed in the control system. RMS 260 is modified with respectto a legacy RMS, e.g., RMS 160, to consume, understand, and controlself-describing Modules, such as Module 292.

Remote monitoring agents are ported from NetLinx to a Java environmentin the form of three Modules: an RMS core Module 246 a, an RMSscheduling Module 246 b, and an RMS dialog Module 246 c. RMS schedulingand dialog Modules 246 b-246 c are “add on” applications.

The RMS Modules 246 a-246 c are configured to describe theircapabilities through capabilities objects. However, the RMS Modules 246a-246 c do not use the component SDK class structure because they areapplications and thus do not represent a device.

Remote monitoring agent 246 is loaded on the master controller 240 inthe same manner as other Modules. When integration IDE 230 is configuredto consume and process self-describing Modules, e.g., Module 292, itwill likewise be configured to consume and understand RMS Modulesnatively.

Router 244 is implemented to query and expose the capabilities of theRMS Modules 246 a-246 c. NetLinx-based devices may use router 245 toaccess RMS capabilities and participate in the RMS monitoring system.

Remote monitoring agent 246 is configured to use native OSGi methods todiscover and access all self-describing Modules, e.g., Module 292,active on master controller 240. Agent 246 then queries each Module todetermine its version. If the version indicates a self-describingModule, the agent 246 will request the Module return a capabilitiesobject. If the version indicates a non-self describing Module, themodule.xml file packaged in the module's jar file will be examined todiscover its device type and capabilities. The RMS agent will generate asparsely populated capabilities object from the retrieved module.xmlfile to describe the corresponding non-self describing Module.

The remote monitoring agent 246 may register each device 270 associatedwith a self-describing Module 292 by sending a registration to the RMS260 server. The device registration may include the self-describingModule's XML file 296 that provides a description of the capabilitiesexposed on the controlled device 270.

The remote monitoring agent 246 utilizes the capabilities object 298from each self-describing Module 292 to request status or invokecommands on the corresponding self-describing Module 292. The remotemonitoring agent 246 may use reflection on legacy, non-self describingModules to match the Module's capabilities with associated methods toinvoke corresponding capabilities. The remote monitoring agent 246 willsimply request status or command invocation from self-describing Modulesas they will handle their own reflection on their internal components.

The RMS 260 server will use the device's XML description to construct aGUI display for administrators to allow selection of properties tomonitor, view acceptable ranges, and invoke commands to control thedevice. The RMS 260 server may require registration for controlleddevices in a self-describing XML format. The remote monitoring agent 246is responsible for producing this XML from devices controlled bynon-self describing Modules, self-describing Modules, or NetLinx code.

When a remote monitoring agent 246 is installed on master controller240, devices controlled by master controller 240 with correspondingdevice capabilities will appear on the RMS 260 server GUI for theadministrator to configure and control.

Remote monitoring agent 246 will automatically discover and describe thestandard and custom capabilities of all active Modules. RMS 260 isadvantageously not tied to any version of device SDK APIs since themodule.xml file of non-self describing Modules will be available todescribe corresponding Modules and self-describing Modules will describethemselves.

In accordance with embodiments, mechanisms for the discovery andregistration of controlled devices associated with self-describingModules in a control system are provided. A controlled device associatedwith a self-describing module is coupled with a master controller onwhich the self-describing module is installed. A remote monitoringsystem is communicatively coupled with the master controller, and aremote monitoring system agent is installed on the master controller.The agent discovers a Module associated with the controlled device andqueries the Module for a version thereof. The agent then evaluateswhether the Module is self-describing. In the event the Module isself-describing, the agent requests a run-time capabilities object fromthe Module and registers the controlled device with the remotemonitoring system according to the capabilities object. In the event aModule associated with another device is discovered that is notself-describing, the agent may generate a capabilities object andregister the other device with the remote monitoring system according tothe generated capabilities object.

FIG. 6 is a flowchart 600 that depicts processing of a remote monitoringagent discovery and registration routine in accordance with anembodiment. The processing steps of FIG. 6 may be implemented ascomputer-executable instructions executable by a processing system, suchas processing of the remote monitoring agent by master controller 240depicted in FIG. 2.

The discovery and registration routine is invoked (step 602), and theremote monitoring agent including ported Modules 246 a-246 c isinstalled at the master controller (step 604). The remote monitoringagent 246 then discovers a Module, e.g., by using native OSGi methods(step 606). Upon discovery of a Module, the remote monitoring agent 246queries the Module for the Module version (step 608). The remotemonitoring agent then evaluates the Module version to determine if theModule comprises a self-describing Module (step 610). In the event theModule is not a self-describing Module, the RMS agent may then obtainthe Module's Module.xml file, e.g., from the Module's jar file (step612). The remote monitoring agent then determines the device type andcorresponding capabilities (step 614) and thereafter generates acapabilities object for the non-self describing Module (step 616). Thediscovery and registration routine may then register the controlleddevice associated with the Module on the RMS 260 (step 622).

Returning again to step 610, if the Module is evaluated as aself-describing Module, the remote monitoring agent then issues arequest to the Module for the Module's capabilities object (step 618),and awaits receipt of the capabilities object (step 620). The remotemonitoring agent then registers the controlled device on the RMSaccording to the capabilities object according to step 622.

The remote monitoring agent then may attempt to discover another Module(step 624), and if one is identified, the remote monitoring agentqueries the Module for the Module version according to step 608. When noadditional Modules are discovered by the RMS agent, the discovery andregistration routine cycle ends (step 626).

FIG. 7 is a flowchart 700 that depicts processing of a control routinefor controlling or accessing a controlled device in accordance with anembodiment. The processing steps of FIG. 7 may be implemented ascomputer-executable instructions executable by a processing system, suchas processing of the remote monitoring agent by master controller 240depicted in FIG. 2.

The control routine is invoked (step 702), and the remote monitoringagent receives a command or status request to be performed on acontrolled device from RMS 260 (step 704). The remote monitoring agentthen evaluates whether the Module of the corresponding controlled deviceis self-describing (step 706). In the event the Module is notself-describing, the remote monitoring agent may then access thecapabilities object of the Module (step 708), e.g., the capabilitiesobject generated at step 616, and thereafter use reflection on theModule (step 710). The command/status request may then be evaluated forconformance with the capabilities object (step 714).

Returning again to step 706, in the event the Module is identified asself-describing, the remote monitoring agent may then access thecapabilities object, e.g., the run-time capabilities object obtained atstep 620, of the self-describing Module (step 712) and evaluate whetherthe command/status request conforms to the capabilities object accordingto step 714. If the command/status request does not conform to thecapabilities object, the remote monitoring agent may issue a fault (step716), and the control routine cycle may then end (step 720). If thecommand/status request conforms to the capabilities object, thecommand/status request may then be invoked (step 718), and the controlroutine cycle may then end according to step 720.

As described, mechanisms for the discovery and registration ofcontrolled devices associated with self-describing Modules in a controlsystem are provided. A controlled device associated with aself-describing module is coupled with a master controller on which theself-describing module is installed. A remote monitoring system iscommunicatively coupled with the master controller, and a remotemonitoring system agent is installed on the master controller. The agentdiscovers a Module associated with the controlled device and queries theModule for a version thereof. The agent then evaluates whether theModule is self-describing. In the event the Module is self-describing,the agent requests a run-time capabilities object from the Module andregisters the controlled device with the remote monitoring systemaccording to the capabilities object. In the event a Module associatedwith another device is discovered that is not self-describing, the agentmay generate a capabilities object and register the other device withthe remote monitoring system according to the generated capabilitiesobject.

The flowchart of FIGS. 4 and 6-7 depict process serialization tofacilitate an understanding of disclosed embodiments and are notnecessarily indicative of the serialization of the operations beingperformed. In various embodiments, the processing steps described inFIGS. 4 and 6-7 may be performed in varying order, and one or moredepicted steps may be performed in parallel with other steps.Additionally, execution of some processing steps of FIGS. 4 and 6-7 maybe excluded without departing from embodiments disclosed herein.

The illustrative block diagrams depict process steps or blocks that mayrepresent modules, segments, or portions of code that include one ormore executable instructions for implementing specific logical functionsor steps in the process. Although the particular examples illustratespecific process steps or procedures, many alternative implementationsare possible and may be made by simple design choice. Some process stepsmay be executed in different order from the specific description hereinbased on, for example, considerations of function, purpose, conformanceto standard, legacy structure, user interface design, and the like.

Aspects of the present invention may be implemented in software,hardware, firmware, or a combination thereof. The various elements ofthe system, either individually or in combination, may be implemented asa computer program product tangibly embodied in a machine-readablestorage device for execution by a processing unit. Various steps ofembodiments of the invention may be performed by a computer processorexecuting a program tangibly embodied on a computer-readable medium toperform functions by operating on input and generating output. Thecomputer-readable medium may be, for example, a memory, a transportablemedium such as a compact disk, a floppy disk, or a diskette, such that acomputer program embodying the aspects of the present invention can beloaded onto a computer. The computer program is not limited to anyparticular embodiment, and may, for example, be implemented in anoperating system, application program, foreground or background process,driver, network stack, or any combination thereof, executing on a singleprocessor or multiple processors. Additionally, various steps ofembodiments of the invention may provide one or more data structuresgenerated, produced, received, or otherwise implemented on acomputer-readable medium, such as a memory.

Although embodiments of the present invention have been illustrated inthe accompanied drawings and described in the foregoing description, itwill be understood that the invention is not limited to the embodimentsdisclosed, but is capable of numerous rearrangements, modifications, andsubstitutions without departing from the spirit of the invention as setforth and defined by the following claims. For example, the capabilitiesof the invention can be performed fully and/or partially by one or moreof the blocks, modules, processors or memories. Also, these capabilitiesmay be performed in the current manner or in a distributed manner andon, or via, any device able to provide and/or receive information.Further, although depicted in a particular manner, various modules orblocks may be repositioned without departing from the scope of thecurrent invention. Still further, although depicted in a particularmanner, a greater or lesser number of modules and connections can beutilized with the present invention in order to accomplish the presentinvention, to provide additional known features to the presentinvention, and/or to make the present invention more efficient. Also,the information sent between various modules can be sent between themodules via at least one of a data network, the Internet, an InternetProtocol network, a wireless source, and a wired source and viaplurality of protocols.

What is claimed is:
 1. A method, comprising: discovering a moduleassociated with a controlled device by an agent associated with a remotemonitoring system; evaluating whether the module is self-describing atruntime; responsive to determining that the module is self-describing,requesting a run-time capabilities object of an object-orientedprogramming language from the module; receiving the run-timecapabilities object; and registering the controlled device with theremote monitoring system according to the run-time capabilities object.2. The method of claim 1, wherein discovering the module comprisesdiscovering the module by invoking an OSGi method by the agent.
 3. Themethod of claim 1, wherein evaluating whether the module isself-describing comprises evaluating the version of the module.
 4. Themethod of claim 1, further comprising: receiving a command for anoperation to be performed on the controlled device; determining themodule is self-describing; accessing the capabilities object; andinvoking the command responsive to determining the command conforms tothe capabilities object.
 5. The method of claim 1, further comprising:discovering a second module associated with a second controlled deviceby the agent; evaluating whether the second module is self-describing;responsive to determining the second module is not self-describing,determining a device type and capabilities corresponding thereto; andgenerating a second capabilities object based on the capabilitiescorresponding to the device type.
 6. The method of claim 5, furthercomprising registering the second controlled device with the remotemonitoring system according to the second capabilities object.
 7. Themethod of claim 6, further comprising: receiving a command for anoperation to be performed on the second controlled device; determiningthe second module is not self-describing; accessing the secondcapabilities object; performing reflection on the second capabilitiesobject; and invoking the command responsive to determining the commandconforms to the second capabilities object.
 8. The method of claim 1,further comprising: querying each of a plurality of device componentclasses for their respective run-time capabilities objects comprisingcommands, parameters, and properties; and accumulating the run-timecapabilities of the plurality of device component classes into a devicecapabilities class.
 9. A non-transitory computer-readable mediumcomprising computer-executable instructions for execution by aprocessing system, the computer-executable instructions, when executed,configured to cause the processing system to: discover a moduleassociated with a controlled device by an agent associated with a remotemonitoring system; query the module for a version of the module;evaluate whether the module is self-describing at runtime; responsive todetermining that the module is self-describing, request a run-timecapabilities object of an object-oriented programming language from themodule; receive the run-time capabilities object; and register thecontrolled device with the remote monitoring system according to therun-time capabilities object.
 10. The non-transitory computer-readablemedium of claim 9, wherein the instructions that discover the modulecomprise instructions that, when executed, cause the processing systemto invoke an OSGi method by the agent.
 11. The non-transitorycomputer-readable medium of claim 9, wherein the instructions thatevaluate whether the module is self-describing comprise instructionsthat, when executed, cause the processing system to evaluate the versionof the module.
 12. The non-transitory computer-readable medium of claim9, further comprising instructions that, when executed, cause theprocessing system to: receive a command for an operation to be performedon the controlled device; determine the module is self-describing;access the capabilities object; and invoke the command responsive todetermining the command conforms to the capabilities object.
 13. Thenon-transitory computer-readable medium of claim 9, further comprisinginstructions that, when executed, cause the processing system to:discover a second module associated with a second controlled device bythe agent; evaluate whether the second module is self-describing;responsive to determining the second module is not self-describing,determine a device type and capabilities corresponding thereto; andgenerate a second capabilities object based on the capabilitiescorresponding to the device type.
 14. The non-transitorycomputer-readable medium of claim 13, further comprising instructionsthat, when executed, cause the processing system to register the secondcontrolled device with the remote monitoring system according to thesecond capabilities object.
 15. The non-transitory computer-readablemedium of claim 14, further comprising instructions that, when executed,cause the processing system to: receive a command for an operation to beperformed on the second controlled device; determine the second moduleis not self-describing; access the second capabilities object; performreflection on the second capabilities object; and invoke the commandresponsive to determining the command conforms to the secondcapabilities object
 16. A control system, comprising: a controlleddevice having a self-describing module associated therewith; a remotemonitoring system; and a master controller on which the self-describingmodule and an agent associated with the remote monitoring system areinstalled, wherein the agent is configured to discover the module, querythe module for a version of the module, evaluate whether the module isself-describing at runtime, determine that the module isself-describing, request a run-time capabilities object of anobject-oriented programming language from the module responsive todetermining that the module is self-describing, receive the run-timecapabilities object, and register the controlled device with the remotemonitoring system according to the run-time capabilities object.
 17. Thesystem of claim 16, wherein the agent determines the module isself-describing by evaluating the version of the module.
 18. The methodof claim 16, wherein the agent receives, from the remote monitoringsystem, a command for an operation to be performed on the controlleddevice, accesses the capabilities object, and invokes the commandresponsive to determining the command conforms to the capabilitiesobject.
 19. The system of claim 16, wherein the agent discovers a secondmodule associated with a second controlled device, evaluates whether thesecond module is self-describing, determines a device type andcapabilities corresponding thereto responsive to determining the secondmodule is not self-describing, and generates a second capabilitiesobject based on the capabilities corresponding to the device type. 20.The system of claim 19, wherein the agent registers the secondcontrolled device with the remote monitoring system according to thesecond capabilities object.